Search engine optimization is a popular method currently used in the “regular” (i.e. non-IoT) Internet to influence web search engine results. From experience, it has been found that, in the majority of cases, a human user will select only from the first few returned uniform resource identifiers (hereinafter referred to as URIs) from a web search even though the total number of returned URIs may be in the order of hundreds or thousands of URIs (e.g. many pages of Google search results). That is, only the first few URIs at the top of the first returned web search result page are typically selected by the user, all the other URIs are typically ignored and never clicked on.
For regular Internet searches, the returned URIs are HTTP based. Technically, this means that the first part (i.e. scheme) of the URI specifies “http(s)”. For example, “http://www.bestcars.com” or “https://mybank.com” are examples of HTTP URIs.
The fact that a human user will typically focus only on the first few returned URIs from a web search is both a cause and effect of search engine optimization. That is, human users have become conditioned to the fact that modern search engines are implicitly putting the best search results at the top of the returned list of URIs. Search engine optimization refers to a set of techniques used by website developers to help ensure that search engines rank their websites relatively higher.
FIG. 1 illustrates a popular search engine optimization technique that is often referred to as cross-linking or sometimes as inbound linking. This cross-linking technique is to ensure that a given website is pointed to from other websites. Websites that have a lot of cross-links pointing to them are ranked higher by search engines as cross-linking is considered a strong measure of the popularity of the website. The cross-linking is detected by web crawlers that a search engine regularly sends out to crawl and map the World Wide Web.
Another popular search engine optimization technique is to ensure that the website content uses selected key words. This is because search engines use the frequency and distribution of certain key words in a web page as part of the input into their ranking algorithms. Again these key words are detected by search engine web crawlers.
The current IoT model for supporting Internet resource searches is very simple and does not support any advanced search-engine-optimization-like concepts. In the current IoT, the key search node is the resource directory that stores URIs pointing to IoT resources. These URIs are pushed directly into the resource directory by IoT servers instead of being discovered by web crawlers as typically done in the regular Internet search engines. The resource directory is then used as a search engine by clients who are looking for a particular IoT resource. The search can be tailored via input parameters from the client as disclosed in, for example, an internet draft of CoRE Resource Directory updated on Dec. 11, 2013 (http://tools.ietf.org/html/draft-ietf-core-resource-directory-01). However, for a given client's search request, the returned list of URIs is flat, unfiltered and potentially very large.
The URIs for IoT may be either HTTP based as per the regular Internet, or may often be Constrained Application Protocol (hereinafter referred to as CoAP) based. CoAP, as disclosed in, for example, an internet draft of Constrained Application Protocol updated on Jun. 6, 2013 (http://tools.ietf.org/html/draft-ietf-core-coap-18), is an optimized web transfer protocol specifically designed for constrained devices but otherwise follows the Representational State Transfer (hereinafter referred to as RESTful) approach of HTTP. RESTful refers to a stateless, request/response model of communication for web transfer protocols.
Similar to the HTTP approach, CoAP URIs can be identified if the first part (i.e. scheme) of the URI specifies “coap(s)”. For example, “coap://tempsensor.floor2.bldg6” or “coaps://securitycamera.home” are examples of CoAP URIs. Also, for IoT, the description of URIs and their attributes and relationships is defined in RFC6690 “Constrained RESTful Environments Link Format” (http://tools.ietf.org/html/rfc6690) and is referred to as “CORE Link Format”.
The following detailed use case illustrates how the current resource directory works and some of its drawbacks. It is assumed that a large factory has 1000 temperature sensors distributed through the building. FIG. 2 illustrates temperature sensors 202, 204, and 206 registering their URIs with a resource directory. As shown in FIG. 2, each sensor 202, 204, or 206 will at start up register (via CoAP Post) their resource (URI) with the local resource directory 208. This will allow the resource directory to build up a database of URIs. In practice, the resource directory is generally localized in scope. For example, a large city may have several resource directories. However, in theory nothing prevents a resource directory 208 from being global in scope. The scope of the resource directory is completely an implementation and deployment choice.
FIG. 3 illustrates an example in which a client 302 queries a resource directory for a list of temperature sensors. After the temperature sensors 202, 204, and 206 register their URIs with the resource directory, a client sends a search query (via CoAP GET) as shown in FIG. 3. The search query requests the resource directory to identify which URIs will provide a temperature reading in the domain of the factory. This is specified through the search parameters which are part of the query.
FIG. 4 illustrates in the same example how a resource directory 208 returns an unfiltered list of temperature sensors in response to the client search query. The resource directory responds (via CoAP GET response) with the complete list of the 1000 temperature sensor URIs that it had registered in its database.
The client's challenge in this current IoT model is illustrated in FIG. 5. From a list of 1000 temperature sensors returned in response to the client's query, which of the 1000 URIs should the client attempt to access? The underlying assumption is that it is not practical for the client 302 to access all 1000 URIs because of constraints in either time, bandwidth, processing power, etc.
As additional background information, oneM2M, as disclosed in, for example, “oneM2M Functional Architecture” oneM2M-TS-0001 oneM2M Functional Architecture-V-0.42, aims to specify a common service layer that can be readily embedded within various hardware and software to support different M2M applications such as connected cars, smart health, etc. The oneM2M as a common service layer basically defines a set of Common Service Functions, for example, Discovery Common Service Function. An instantiation of a set of one or more particular types of Common Service Functions is referred to as a Common Services Entity. A Common Service Entity can be hosted on different types of network nodes such as an infrastructure node, middle node, or application-specific node.
FIG. 6 illustrates the oneM2M functional architecture 600 where: 1) an Application Entity (AE) 602 can access and leverage Common Service Functions in an Common Service Entity (CSE) 604 via Mca interface; 2) an Common Service Entity 604 can communicate with another Common Service Entity 606 via Mcc interface; and 3) an Common Service Entity 604 can also leverage Network Service Entity (NSE) 608 from underlying networks via Mcn interface. For example, an M2M Server as a Common Service Entity has Discovery Common Service Function, which can be leveraged by an Application Entity to search resources maintained in the M2M Server or even in other places which the M2M Server has access to.